MSのピークアノテーション(櫻井)精密質量MSのピークアノテーションにおける、イオン化状態(アダクト)の判定アルゴリズムを完成させる完成させた。1)指定した上限数の中性の脱離・付加(H2O、アセニト等)、および2)イオン化(プロトン付加、ナトリウム付加等)の組み合わせを解析して、適切なイオンの状態を判別できるようにした。糖鎖構造のRDF化とSPARQL(山田、新町)国際糖鎖構造リポジトリGlyTouCanにおいて現在利用している検索ツールは、Glcを検索する場合でもGlcNAcを含んで検索してしまう問題がある(だから今使ってない)。この問題を糖鎖線形表記(WURCS)をRDF化したWURCS-RDFとSPARQLで構造検索を実現したい。"false")は”曖昧でないグリコシド結合"をそれぞれ検索する方法テスト糖鎖10個において、検索できた。..."部分をコメントアウトするだけではダメで、目的の糖鎖構造が取得できなかった。..."と"wurcs:has_GLIP"のFILTERを組み合わせることで、ID2~ID10は目的の検索ができたが、ID1はダメだった。true"を除くことができた。〜ありがとうございました岡別府さん〜(2/4-5)GlyTouCanに含まれる36488個の糖鎖(WURCS-RDF)に対してID1の糖鎖構造を検索したところ、約50秒かかった。SAPRQLの改良を検討したい。(山田)(2/5)検索に時間がかかったのは、仮想環境のVirtuosoを利用したからみたい。糖鎖グループのテスト環境で実行したところ、5秒以内には検索できた。(山田)(2/5)今後の方針:入力された糖鎖構造のWUURCS文字列から、構造の特徴(特にwurcs:isFuzzy)を加味したSPARQL文の生成の検討を行う予定。match(ESM)を実行するSPARQLはできた。ための基本単糖(WURCS-Basetype)の検討(山田)(2/5~6)目的:糖鎖の領域では単糖が何なのか明確でないところがある。基本的にはポリヒドロキシアルデヒドやポリヒドロキシケトンおよびその誘導体として理解されているが、GlcNAcはGlcの誘導体と考えるよりは、別の単糖であるとすることが一般的なようである。硫酸化単糖の硫酸化部分は単糖の修飾と考えられることがある。このような曖昧な部分を基本単糖(WURCS-Basetype)を定義して明確としたい。WURCS-Basetype:WURCSで定義する基本単糖のこと(まだ脳内レベル)。これは、アノマーや9位の修飾情報などを含んでいる。単糖の種類はN-アセチルノイラミン酸である。N-アセチルノイラミン酸のWURCS-Basetypeは”akd21122h_5*NCC/3=O”となる。削除:アノマー(2a)削除:環(2-6)削除:9位の修飾(9*OCC/3=O)置換:SkeletonCode内のアノマー位の立体情報(6)をケトン”k”へ(アルドースの場合は”o”)置換:修飾によりSkeletonCodeの文字が標準から異なっている場合など(例えば,”A”->”a”)しかし、5位のNAcは、ノイラミン酸の炭素骨格に結合している酸素原子がNAcに置換したものであるため残す。652個のWURCS-Basetypeがえられた。WURCS-Basetypeでは、基本となるポリヒドロキシアルデヒドやポリヒドロキシケトンの炭素骨格に結合している酸素、水素が置換されている場合は、該当する修飾は残すことにしている。この処理で、GlcNAcがGlcとなってしまうことが防ぐことができる。デオキシ糖(Fucなど)も同様にWURCS-Basetypeとしてカウントされる。糖鎖構造の線形文字列表記(WURCS)を、WURCS-RDF形式へ変換するツールの改良GlyTouCanに含まれる36488個の糖鎖をWURCS-Basetypeのトリプルを加えてWURCS-RDFを作成。天然物(アルカロイド)骨格分類データベース天然物骨格DBに骨格構造をMolfile(V2000)形式で保存、このDBのIDを仮IDとして利用する。(2/3)chemdoodleを利用した骨格の化学構造表示に一部変更~結合表示等の問題解決のため~(2/4)今後、化学構造(糖鎖構造)をSVGで表示するStanza:JavaScriptを作りたい。骨格の階層分類の方針:天然物(アルカロイド)の生合成をデータ化しながら、骨格を抽出して階層について検討する。Products)に似た構造になると考えている。参考SPARQLThon/天然物SPARQLThon20化合物の中には複数のコンポーネントから生合成されているものがある。databaseなどに含まれるpathwayとの関連付けが望まれる)metaboliteでKEGGのIDと1対1の対応が付けることができないcompoundは多く存在する。自動アノテーションが実現されればこの問題の解決の第一歩となる。(expertでない者はそのような対応付けを行うことができない)。pathwayとの対応関係でしたら、できるかも知れません。試してみます(小寺)自動生成とは独立に生合成知識ベースでの骨格のデータベース化と階層分類(Ontology?)は必要と思いますがどうでしょう(時松:作業中)はい、必要だと思います。知識ベースのほうは、ぼくはしばらく手を出せないと思いますので、よろしくお願いします。将来的には、それとKCF-Sとの対応関係も整理できると良いですね。(小寺)はいほぼ仰る通りです。pathwayとの対応関係が知れると非常に助かります。DRUGとの関係もわかるようであれば研究の幅が確実に広がると思います。(最悪の場合)名前しか情報として持たないようなmetaboliteのlistからでもpathwayをlistupしてくれるような機能があると助かる、と考えています。”aspirin”を調べてみる。これで、aspirinのInChIや他のDBのID、シノニムが取得できるので色々使えるのでは。取得できたIDがどのDBのIDかの情報はないので注意。NBDC版日化辞では日本語でも検索できるようになる予定です。(山田)(2/5)情報ありがとうございます。化合物アラインメントによる自動計算結果を蓄積することはできないでしょうかね?(小寺)蓄積方法を考えたいですね。原子レベルに加えて、生合成のビルディングブロックのトレースを蓄積、表示できる方法がほしいなと(時松)原子レベルで化学構造とトレース情報をRDFで蓄積するのはどうですか?そのために、SIO,ChemInfなどを調査する予定。記述するのはなさそうだ。RDFでどう表現するかという問題はありますが、いちおうデータソースとして使えると思います。原子レベルではなく部分構造レベルにしようと思ったら、どうすればいいか現在よく分かりませんけどね。今のところ、作成した代謝産物骨格については手作業で生合成ユニットの由来情報をメモしています(atom-to-atomまではしていません)。(時松)なるほど、そうですよね。mappingを計算して、手作業で直したものを集めるという流れでやることになるんでしょうね。E-zymeのオプションでやるほうがやりやすいかも知れませんが。(1)だけでも大仕事になりそうですね。(小寺)方向性はそんな感じかと思います。今のところ、まだ整理の段階で手作業で構造式描画ソフトなどで頭を整理している段階です。上記の作業をするためのワークフローについては、今後SPARQLthonで詰めていきたいと思います。(時松)上にリストアップしたタブ区切りファイルは、KCF-Sと原子との対応関係を表現したものではありません。原子との対応関係を含めたデータもあるにはあります。RDFでどう表現するかという問題は解決されていません。(小寺)トレース情報を化学構造に重ねて表示するなどの機能を持ったStanzaを作りたい。(山田)(2/4-5)どんなイメージでしょうか?たとえば、入力化合物を指定して、5ステップ後の化合物(最終生成物)を指定すれば、最終生成物中にある、入力化合物由来の原子が赤く表示されるという感じでしょうか?(小寺)(最終)生成物中にある、由来化合物の原子を由来毎に色分けして化学構造を表示させるような機能があるStanzaを作りたいと思っています。どのように色分けするかとかまでは、まだ考えていません。(2/3)LinkDBには、KEGG内部のIDリンク情報がない。drugは日化辞IDとつながっている。以下のRDFを取得すればできそう。downloadNBDC版日化辞RDF(下記参照)が公開されれば、可能になる予定。databaseを参照しても、二次代謝産物の多くはそれらと関連が付かない。dataを提供していない。pathway情報を記録したbiopaxがRDFとしては入手可能だが、登録制でIRI(URI)はそのbiopax内でしか使えない。wikipathwaysのxml(GPML)のvisualization用vocabularyが用いられている。FeedBackフラボノイドに複数の修飾官能基がある化合物など複雑な二次代謝産物については、現状データベース側のSynonym表記の問題でMetMaskでIDを拾いきれてない状況がありそう。上記で見たAtMetのデータは理研測定データのSubsetなので、測定可能化合物データについて検討中。会期内には終了しないので継続作業として持ち越し。<http://chem.sis.nlm.nih.gov/chemidplus/rn/93966-58-6>.トリプルストアの準備(三橋@東京)virtuosoのインストール完了、起動確認。Unportedのライセンスで利用することができます。プライバシー・ポリシーTogoWikiについて。