2012開発

=内部での調査もの=

ARSA

 * 検索結果が腑に落ちないことが　chunking が不明
 * 検索結果からpage back 出来ないと　いろんな条件を工夫してると非常に不便です
 * ワイルドカードが効かず　一方で　word 全一致でないといけないので　mitochondria, mitochondrial, mitochondrion と全部書かないといけない

DDBJ release file data を対象にする査読

 * 1) Field 内の表記揺らぎの検討
 * 2) 全ゲノムなどを取り出すパタンの検討
 * 3) 名寄せ問題
 * 4) Named entity identification ->indexing ->mutuallink, external
 * 5) Division のobservatoryな特徴付
 * 6) 全ゲノムはどこにある？
 * 7) 16Sはどこにある

=SAKURA=
 * 4月中に仕様を決定して　えい和に発注　　小菅さんと考える約束になってます.

=外部のデータセット置き場=
 * 小笠原さんが守山渡辺さんたちと移行用に仕組みを作りましたが　スパコンでは製作所が医科研ゲノムセンターのミラーをコピル方策をとっているようです. 　長期的に考えて交通整理と投資が必要.
 * 小笠原さんと昔話した時には　あらゆるデータをFTPにおくだけでなく　バージョンやサイズ　更新履歴なすにぺとなどのメタデータ付の表が目立つところにあり　常に　どの仕事には　何を使ったかを　バージョン情報を見なくても　タイミングで知れるのがいいですねと

=開発仕様　2012-1: CIBEXサーバーの故障に伴う対応= 原　夫妻で対応可能か？？
 * 背景:CIBEXはxxx年に池尾舘野らによって提案されたマイクロアレイデータ共有のための公共アーカイブです.
 * 現在のCIBEX
 * 予算面：
 * 機能１：ウエブwizzard形式でメタデータを記入してもらい、データはftpしてもらう.
 * 機能２：検索法は？？
 * 経緯：池尾さんたちとSKの開発. 　池尾さん購入のサーバですべてが完結していたた. 　受付はアノテータの児玉さんが行い登録公開は全くそのままで継続していました. クレジット面でも変化なし. 　x月ｘ日にサーバーが機器エラーで停止し、その復旧について池尾准教授にコンタクトし、本サービスの維持はDDBJ事業であり本人には維持継続努力の意思のないことを確認.
 * サービス期間：
 * 登録数：　年間10件
 * ヒット数：
 * データダウンロード歴：
 * 受付データ以外のGEOデータ等の提供：

データ別に入口があり別の文法に従ってしか探せないのは気が利かない
 * 開発内容：利用度から考慮して登録や検索面に関して現状の機能復旧に注力することは適当でないと判断. 　但しすでにうけた登録に関して取り出せない状況を作るべきでないので、受付番号およびいくつかのメタデータフィールドでデータを取得できる最低限の機能を再現する.
 * データのダウンロードサイトでかまわない.
 * スコープがあまりに小さいのでDRAのメタデータやバイオプロジェクトのメタデータもgetentry ARSAで検索にのせるのようにしてもよい.


 * DOR? で発現データは？　　ファイルtransferの一般系があればいい. 　　登録人情報や番号発行や公開非公開の制御も一般化可能
 * 出口もファイル検索だけならばARSA-GETENTRYと同じ

=開発仕様 2012-2: テンポラリーサーバからの全事業の載せ替え=
 * daily 作成, release 作成, gententry, ARSA, DRA などのサービスを移行用の低機能サーバからスパコンクラスタに載せ替える.
 * 間に合わせで行わずに、しっかりと設計して安定稼働するように載せ替える.
 * 1) Getentry
 * 2) *getentryプログラムの機能と構造の説明
 * 3) *対象データとその量　伸び率
 * 4) *理想的な稼働リソースのとその実現法
 * 5) ARSA
 * 6) *プログラムの機能と構造の説明
 * 7) *対象データとその量　伸び率
 * 8) *理想的な稼働リソースとその実現法
 * 9) BLAST　　RNAi山田４月前半駆動予定
 * 10) Taxonomy: NCBIを指すことで対応中. 復興時には日本語対応、BigContext対応,等仕様策定中
 * 11) CLUSTAL-W: 同じファンクションをGalaxyが提供しているならそちらがいい. 　コマンドラインで動くほうがいいかもしれない　RNAi山田４月前半駆動予定
 * DRA
 * 1) *現在運用中のシステムの単純移行
 * 2) **DRA DBサーバのDB構築,データ移行,アプリケーション移行
 * 3) **管理系サービスサーバのapache,tomcat,アプリケーション移行
 * 4) **受付バッチ処理サーバのアプリケーション移行,SRA toolkitのインストールと動作検証
 * 5) **SRAtoolkit Web実行サーバのtomcat,アプリケーション移行
 * 6) **キーワード検索サーバのSolrの構築,インデクス移行,アプリケーション移行
 * 7) **データ移行
 * 8) **登録データ受付サーバのサーバ構築
 * 9) **BioProjectバッチ処理実行サーバのアプリケーション移行
 * 10) **SRAMetadataミラー処理実行サーバのアプリケーション移行
 * 11) **SRARunデータミラー処理実行サーバのアプリケーション移行
 * 12) **外部向けサービスWebサーバのapache,tomcat構築,アプリケーション移行
 * 13) *UGEに対応したシステムへ改変
 * 14) **Dra Batch（生データ to SRA)
 * 15) **SRA run importerの一部FASTQ dump(SRA&ENA to FASTQ)

=開発仕様 2012-3: メタデータ統括　その１　登録行為登録者などの管理の統括=

DDBJが登録を受け付けるデータ種別は近年多様化を続けています. 配列登録票だけでなく生データ、プロジェクト情報、マイクロアレイデータ等です. これまではSAKURA,MSS,DRA,CIBEX,BioProject　等独立に受付管理系を作ってきましたが利用者が不便なだけでなく管理コストが増加する一方です. データ自身はサイズや形の制約をうけるがメタデータは人間の入力による説明ですから共通化が可能のはずです. さらに登録受付行為の記録については形式は自由であり、３極交換もされません. これまでここにも無用な自由度があったようです.

D-wayといってきたものとのデマケが必要ですが　D-wayがよく D-wayは登録者情報入力の一元化は目指していない？ データの置き場所もBioProjectとSRAメタデータは別？のDBにたまっている ので目標は違うようです. D-way計画で新たに登録法が二つできてデータベースが２つ検索系表示系も二つできています

１．SAKURA, MSS, CIBEX, Bioproject, SRA なんでも メタデータの階層化 ①受付行為の特徴--②データの解説ダブリンコア的な部分（登録者、文献、公開非公開、公開日）--生物学的コア部分（生物種の特徴？細胞の特徴？コンテキストの特徴）--測定法固有の部分　に階層化可能ではないか？

それをにらんでデータの説明ではなく登録受付行為(内部記録）の記述法を一元化する. (オントロジー的な話、受付行為のモデル化）
 * これにより人間や施設の管理は統一する
 * 登録行為以外の公開用のメタデータについても 生物名、文献データなど外部の参照情報の記述管理法を共通化する


 * データ交換に使われる形式は管理の容易な形式から書き換えて作るくらいのことを目指す

=開発仕様 2012-3　登録行為　利用行為にかかわる表現 （年度報告のリアルタイム版）FUN PROJECT IN PART=
 * これまでの統計はw-DDBJを出発データにする統計だけでした. これなら外部機関でもつくれます. 登録行為ログに基づく管理
 *  has feature 登録者　登録日　登録データ データ量　公開非公開
 * きればリアルタイムに表示したい
 * イメージはDDBJ Report 2011
 * 1) mailMaildealer
 * 個別
 * 1) Master-slave division 別に
 * 2) Raw　type別
 * 3) BioPro


 * 表現部分１　Academic Domain Sorter:
 * ドメイン名やIPを機関名に変える.
 * 機関名は国内国外や国別などに分類されている
 * 機関名はネットプロバイダと企業に分割できる
 * 特別に多い施設は固有名を抜し表現も可能
 * 表現部分２　Domain-coordinate 変換機
 * ドメイン情報をいろいろ駆使して緯度経度に変える


 * J-gloal や機関名辞書など外部資源で片付く部分はなるべく持続的に他者により更新されるものを利用すること
 * 登録者や著者の同定はこのカテゴリでやるのか　それとも　固有名称同定の別プロジェクトか？

=開発仕様　2012-4 登録全体の生物学的表現= 原夫妻と大久保がやります
 * 目次のコンセプトに近い 利用者に生物学的なデータ全貌を伝える　利用促進　発見促進的提示
 * 全メタデータを出発材料にgetentry ARSAが提供する検索と相補的になるように内容によるインデックスを行う
 * 入口に置くと目次　出口におくとgetentry ARSAのドリルダウンに


 * Oga-parserの下流の計画のはず. 　Oga-parserはどうなった？？


 * フィールド占拠パタンによる全レコードのクラスタリング　　値があれば１なければ０の　record ID x Field の特徴行列　スパコンでできないか？？