---
# System prepended metadata

title: TogoID 2021年度開発会議　議事録

---

# TogoID 2021年度開発会議　議事録
## 2021/07/08

### そもそも: togoid の位置付け

- [ ] ストイックにID-IDの関係をresolveすることに徹する
- [x] 「tsvでペアを作って突っ込むと解決できる」に即していれば柔軟に受け入れる
  - `UniProt mnemonic` のようなものがすでにある
- [x] IDを突っ込むとdescやlabelが取れるようなサービスとして拡張する


### データ　(DBCLS作業)

- Gene symbol がIDのように扱われている現状がある
    - ツールやサービスの入出力に使われている
    - 既存の仕組みを使って human gene symbol のペアを作ればよさそう
    - UniProt mnemonic のような扱いになる
    - もともとのToDO
        - 入力はシンボルではなくIDであることをわかりやすく書く
        - （遺伝子なら、○○DBのID, とかいう例示を含め）
        -    → HGNC symbol への対応を次期？ (6/15)
- pubchem_compoundとpubchem_substanceのペアも欲しい!

### API

- "not converted" を返す？ => いらない
- route の forword, reverse 指定。今は forword 優先で自動的に決まる


### UI

- 変換先を先に指定してパスを決めたい
  - 変換先の ID はユーザーの頭の中にあるはずなので、最初にそれを指定させるのが直感的
  - 現状だとワンステップで変換ができなかった場合、変換先 ID に至るパスはユーザーが見つけなくてはならない
  - 変換先に応じて、可能なパスを提示したほうがよい
- ヒットしなかったものも出力のテーブルに含めたい
  - データを入れて、DBの経路を絞りこんでいくと、絞り込みに該当しないデータについては、最終的に結果無という状態になってしまうが、投入した全てのデータに対して、結果を返すのも良いのでは
  - どこまで関連性のあるデータが拾えているのかが分からなくなってしまう
    - 全体的にAND検索になってしまっている
    - ユーザーのニーズとしてANDもORも必要とされる場合がある
- 同一物を示すIDのあるDBと、関連するが同一ではないものを示すIDのあるDBとを、semanticsで区別したい
    - PATHのところ、つながっているデータベース名だけでなく、どういう関係でつながっているのか表示してほしい
    - semanticsが実装できるなら要らないかも　→逆引きのデータでID変換を表示する場合には、繋がりを示すラインの色を変えるとか、ちょっと工夫があるとよいかも
- 検索結果の表示順はなに?
- データエクスポート
    - Copy target IDs. のピリオド取る
    - コピペボタンの拡充
        - 変換先DBの横にコピーボタン
        - 変換先IDの横にコピーボタン
    - 変換候補にマウスオーバーしたときのDLボタンをコピーボタンに変更
    - API URL の表示
      - 長いやつは？表示はコンパクトにしてコピーできるようにする？
    - 今見えているテーブルがExportできるように、UI上で、フォーマットを変更･指定できると良い。
    - DLをするときのIDはPrefixを付けている方が、どのDBなのか分かりやすいかも
      - →　コンフィグにPrefixを指定して、代表的なID表示でDL出来る方が良いかも(6/15)
      - ↑ 付けるべきだと思います！！prefix の最後の "/" の後ろを付け足せばよい。
      - (例: Disease Ontology では prefix: 'http://purl.obolibrary.org/obo/DOID_' なので DOID_ を足す)(池田) 
      - エクスポート用の希望Prefixがある場合は、dataset.yamlに記載する
          - :　とか　_　とか複数ある場合は、選択できるとよい
- 変換ができなかった ID (出力先に指定した DB と対応が取れなかった入力 ID) をテーブル表示できたほうがよい
    - 技術的に困難?　頑張れそう?
    - Your "XX", "YY" aren't forwarded. について：ID変換を多段階でやって、パスの先の方でID Forwarding結果を見た時にそれまでのどの段階でリンクが切れているのわかると便利だと思う
    - 代替案として、変換候補DBを選択したときにMatched/totalの件数が変化していくとよさそう
- 変換ルートを変えずに、検索IDを変えたい
    - Submitボタンの機能を変更して、Routeクリア機能をなくす
        - Routeがある状態でSubmitが押された場合は、IDが前回とマッチしているか調べる→問題なければ、同じRouteで再計算する
        - IDが前回と変わっていたときは、新規の検索と同じ扱いにする
- "Submit" と "input from text file" のボタンの見た目が一緒なのが認知負荷高め
    - ボタンのデザインや位置を工夫したい
- アイコンの間の隙間もクリッカブルにしてほしい
    - クリッカブル判定の見直し
- 思い出せないシリーズ
  - IDを入れて、DBを選択すると、繋がりのある次のDBを選択する事になるが、IDの変換として、候補で表示されるIDを全データ欲しい場合もあるのでは？と、思われる。例えばMondoからスタートして、それに関連するデータは一通り欲しいけれども、現在のインターフェースだと、一つしか選べない。同じ階層の関連データを複数選んで、データがDLできる機能（モード）があっても良いのでは？と思う
### インフラ/AWS

- TSV更新用 Rakefile を ECS Batch で定期実行 => ロード
- テスト
  - 負荷テスト
  - ロード後のデータ整合性チェック
- モニタリング&通知, オートスケール？
- パフォーマンス向上
  - キャッシュ最適化

### 連携

- LINCのはなし(来年?)
- サードパーティなIDペアの追加機能の実装?


























