技術屋にゃん兵衛のてくてくらぼ by データウィズ [DataWith]

気の向くままソフトについて書いてます。バリバリエンジニアではないのであくまでも初心者目線で。

ChemSketchで簡単「構造>名前」変換とPubChem情報

ChemSketchで簡単「構造>名前」変換とPubChem情報

 

フリーのACD/ChemSketchで、化学構造式からIUPAC名やSMILESを生成できるので、それを書いておきます。

あとついでに、PubChemの検索機能も。

 

ChemSketchは、個人の趣味範囲であれば無料で使えるようなので、ありがたいです。わたしは化学者ではないので、これで研究をすることはありません。

単純に、Pythonなどの環境で化学構造式を扱えるかを確認したいだけなので。

以前に、Google Colaboratoryで化学構造式を書いてみました。

 

ここでは、すでにACD/ChemSketch (Freeware)がインストールされているところから始めます。

 

今回、名前を生成しようと思うのは、次のものです。

 

  1. ツールバーの一番左、「Select/Move」ボタンをクリックして、構造式を囲んで選択します。

  2. 「Tools」>「Generate」>「Name for Structure」を選択します。

  3. あっというまに、IUPAC名が生成されました。

  4. 今度はこの構造式のSMILES形式を生成してみます。「Tools」>「Generate」>「SMILES Notation」です。

  5. こちらもあっという間。

  6. ちょっと蛇足で、ここからPubChemも検索できるようなのでテスト。

  7. 今回は、完全一致を検索(Search Exact Structure)で、結果をChemSketchで表示(In ChemSketch)を選んで「OK」とします。

  8. 少し待つと…

  9. 結果は次の通り。いい感じです。「Indomethacin」(インドメタシン)という一般名がわかります。

企業で業務に使っちゃあいけないのだろうけれども、趣味で使う、学生が使う分にはChemSketchは十分すぎ。

大学で学生に使わせるソフトウェアについて思うこと(続)

前回は大学側の観点から書いたんですが、今回はソフトの開発側から「鶏と卵」の話をしたいと思います。

 

そもそも、なぜ教育用のソフトウェアのライセンスは企業で買う時よりも安いのか?それも格安で。

以下、わたしの考察です。

 

開発側としては、「ソフトウェアを安く提供することで教育に貢献したい」という論理はほとんどないと思います。

こう考えているんであれば、多分間違い。

 

今、大学で使われているソフトを考えると、ほとんどが欧米製です。

つまり、彼らにとって日本の教育や科学技術の発展に貢献する理由があるでしょうか。国際競争の観点で考えると、優秀な人材を自国に取り込みたい、というのが最近の流れだと思うので、例えば、「優秀な留学生はうちに来てほしい」と思うはずです。

 

大学が鶏

では、なぜ、教育用ライセンスは安いのか。

それは、「大学で使っていれば、企業に入ったときに、そのソフトを使い続けたいために企業ライセンスを購入してくれる」という期待があるからです。

大学が「鶏」で、企業が「卵」の関係です。

確かに、これは成り立つ部分はありますが、前回書いたようにこれはすべての場合に割り当てられるわけではないのです。

また、企業が大学の先生と共同研究をするときに、大学の先生に合わせて企業用のライセンスを買うこともあるでしょうが、これはどちらともいえないです。逆のケースもありうるでしょうし。

 

企業が鶏

大学側が「即戦力を育成したいために企業で使われているソフトを導入する」といういう観点からは、大学が「鶏」ではなく、企業が「鶏」で大学が「卵」です。

何か全く新しいソフトが世の中に現れ、それが先に大学に導入され、そこから市場に広まるというのは、まれにしかないのではないかと私は考えてます。

もちろん、大学発のソフトもありますけど、、、

ただ、ビジネスにできるかは微妙かな。大学の先生は大学から給料をもらいながら開発できるけど、企業としては売上をそのソフトからもらわないと、どこからもお金は出てきません。

皆さんはどうでしょうか?

 

全くの他人

「どうせ企業で再教育を受けるのだから」という視点では、ソフトは何でもいいので大学側は独自に決められます。

そうなると、開発元としては教育用のライセンスを安くする理由はなくなります。つまり、大学と企業の関係は「親子ではなく他人」ということになります。

これは、開発元にとっては一番いやなケース。つまり関連がないのに、「大学はお金はないから」と安くしていることになります。

そうなると、本当はもっと高く売りたい、企業にも売りたいと思っているのに、大学で完結してしまうことになります。

 

なかなか、この関係は難しい。なかなかWin-Winとはいきにくいです。

Win-Winは、大学でも企業でも、どちらでもそのソフトが主流となったものだけですね。

 

他にもいろいろ考えつくことがありますが、この辺りでやめておきます。

 

 

大学で学生に使わせるソフトウェアについて思うこと

これは、以前から思っていたことなんですが、改めて文章としてまとめてみたいと思います。

 

大学で学生にあるソフトウェアを使わせようとした時、4つの選択肢があるんじゃないかと。

  1. 教官が自身の研究用に使い慣れたソフトを使わせる
  2. 学生が将来就職するときに即戦力となるように企業が良く使うソフトを使わせる
  3. 大学が大学全体や学部全体で契約しているソフトを使わせる
  4. できるだけコストを抑えられるように無料のソフトを使わせる

これは、それぞれの大学の事情により、違ってくるんでしょう。

 

例えば、学生の多くが大学で教員になったり、企業の研究所に入るような大学の場合、1. の選択肢が筆頭になるでしょう。

今後、共同で論文を書いたり、共同研究をすることも視野に入れるということになります。ただ、あまりマニアックなソフトに走ると、それに使い慣れた学生は、企業に入ったときに、改めてその企業が使っているソフトを勉強することになります。

 

一般の企業で製品開発などを行う進路をとる学生が多い大学では、やはり、即戦力を養成できているという点が就職率に直結するので、そういうソフトになります。これが 2. の選択肢です。

企業向けのソフトは高いものが多いですが、大学用の安いもの、場合によっては「大学は無料!」のものがあるので有力な選択肢です。また、企業ではIT統制の観点から、出所がわからないソフトウェアはインストールできないことが多いため、きちっとした企業が開発したソフトでないと導入しません。

あとは、購入後に使ったときにわからないことがあれば聞くことができる、というのもフリーソフトにはないメリットです。

 

3. は最近減ってきているようですが、大学や学部全体で組織が契約している場合です。自分がそのソフトに「なじんでいれば」いいですが、そうでない場合は自分がそれを勉強しなければなりません(あるいは自分で追加で買うか)。

最近この形が減ってきていて、その理由は「受益者負担」というキーワードがあるためと聞いてます。つまり、「自分の研究室や授業で使っていないのに、なぜ、そのソフトの購入費を負担しなきゃならんのだ。おれは他のソフトが使いたいんじゃ~」という意見が強くなり、「実際に使う人に必要なソフトを買ってもらうほうが公平だ」ということになっているためなんでしょう。

 

4. は、一見乱暴に見えますが、正しい面もあります。つまり、「大学で学んだことをそのまま企業で使えるケースは少ないし、企業に入ったら、いずれにせよその企業の環境を学ぶ必要があるのだから」という論理です。分野によってはまさしくこの選択肢が正しいケースがあります。

例えば、データサイエンスなんかだと、Python(プログラミング言語は無料ですよね)を使ってデータ解析をしたり、R を使って統計処理をするのであれば、費用はかからない上に企業でも即戦力になるケースもあります。

Python なんて、Google Colaboratory を使えば、インストールすることすら不要だしね。

 

これは、分野ごとに見ていくと、なかなか面白いです。

ざっと思いつくところでいくと、、、

 

GNU Octave(Matlab ライクな計算環境)

R / RStudio(統計ソフトでは有名)

Orange(データマイニングソフト)

BIOVIA Draw(大学や官公庁、学生は無料)

ChemSketch(大学や個人使用は無料)

ParaView(可視化ソフト)

OpenFOAM(CFD [Computational Fruid Dynamics] ソフト)

GIMP [GNU Image Manipulation Program](画像 [ビットマップ] 編集ソフト)

Inkscape(画像 [線画] 編集ソフト)

QGIS(地理情報システムソフト)

GRASS GIS(地理情報システムソフト)

 

もっと、バイオや化学の分野ではあるんでしょうね。政府系の研究所などが研究成果としてやっているものが多いですから。

(そっか。であれば、この分野の研究者になるのであれば、フリーのほうがむしろ良い?)

 

なんにせよ、趣味のためであれば、無料の環境はありがたいですよね~。

問題が起きても解決を急ぐ必要もないし。

 

P.S.

以前に Wolfram 言語について書きましたが、企業での利用というのはどれくらいなんでしょう。研究所レベルであれば大学と似たようなものなんでしょうけど。

 

 

XMLBluePrintでXMLからXSDを生成する

XMLBluePrintでXMLからXSDを生成する

 

これまで使ってきた法令のXMLファイルからXSDを生成してみます。

その後、WebでダウンロードできるXSDファイルと比較して、どれぐらい差があるかを見てみます。

 

  1. まずはこれまで通り、法令のXMLファイルをXMLBluePrintで開きます。

    XMLBluePrintで開く
  2. 「スキーマ」メニューから「サンプルXMLからXSDを生成」を選択します。

  3. いくつかの同形式のXMLファイルを指定することで、生成の精度が上がるようですが、まずは、1つのファイルだけでやってみます。

  4. 「OK」をクリックすると、一瞬で生成されます。
    生成されたXSDファイルは、元のXMLファイルのある場所に、拡張子を .xsd に変えて、同じ名前で保存されます。

    生成されたXSD
  5. さて、XSDを比較してみます。今生成されたXSDはタブで切り替えることができますが、2つのXSDファイル、今回は、Webからダウンロードした公式のXSDとXMLBluePrintで生成したXSDを比較したいのですが、タブではうまくいきません。
    実はXMLBluePrintは同じマシンで複数起動できます。なので、もう一度、「スタート」メニューから「XMLBluePrint」を選択するともう1つのウィンドウが開きます。
    この中で、ダウンロードしてきたXSDファイルを開いて、横に並べます。

    XSDファイルを見比べる
  6. 冒頭の次の部分を見てみると、一見違いますが、XMLファイル1つだけでこれが「enumeration」(列挙型)であることはわからないので、仕方がないと思います。

    Webページの公式XSD

    XMLBluePrintで生成されたXSD

    <xs:attribute name="Era" use="required">

            <xs:simpleType>

              <xs:restriction base="xs:token">

                <xs:enumeration value="Meiji"/>

                <xs:enumeration value="Taisho"/>

                <xs:enumeration value="Showa"/>

                <xs:enumeration value="Heisei"/>

                <xs:enumeration value="Reiwa"/>

              </xs:restriction>

            </xs:simpleType>

          </xs:attribute>

    <xs:attribute name="Era" use="required" type="xs:NCName"/>

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  7. これに続く部分はというと、わりとうまくいっていると思います。見やすくするために順番を入れ替えて、並べてます。
    やはり、「enumeration」は1つでは、「他にどんな値があるか」がわからないので、だめです。このセクションでは、「LawType」と「Lang」です。
    あと、オリジナルは「positiveInteger」ですが、生成されたものは「Integer」です。ファイルを見ただけでは、「絶対にすべて正の整数である」とは言い切れないでしょう。

    Webページの公式XSD

    XMLBluePrintで生成されたXSD

    <xs:attribute name="Year" use="required" type="xs:positiveInteger"/>

    <xs:attribute name="Num" use="required" type="xs:positiveInteger"/>

    <xs:attribute name="PromulgateMonth" type="xs:positiveInteger"/>

    <xs:attribute name="PromulgateDay" type="xs:positiveInteger"/>

     

    <xs:attribute name="LawType" use="required">

    <xs:simpleType>

      <xs:restriction base="xs:token">

       <xs:enumeration value="Constitution"/>

       <xs:enumeration value="Act"/>

       <xs:enumeration value="CabinetOrder"/>

       <xs:enumeration value="ImperialOrder"/>

       <xs:enumeration value="MinisterialOrdinance"/>

       <xs:enumeration value="Rule"/>

       <xs:enumeration value="Misc"/>

      </xs:restriction>

     </xs:simpleType>

    </xs:attribute>

     

    <xs:attribute name="Lang" use="required">

    <xs:simpleType>

      <xs:restriction base="xs:token">

       <xs:enumeration value="ja"/>

       <xs:enumeration value="en"/>

      </xs:restriction>

     </xs:simpleType>

          </xs:attribute>

    <xs:attribute name="Year" use="required" type="xs:integer"/>

    <xs:attribute name="Num" use="required" type="xs:integer"/>

    <xs:attribute name="PromulgateDay" use="required" type="xs:integer"/>

    <xs:attribute name="PromulgateMonth" use="required" type="xs:integer"/>

     

     

     

    <xs:attribute name="LawType" use="required" type="xs:NCName"/>

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    <xs:attribute name="Lang" use="required" type="xs:NCName"/>

     

     

     

     

     

     

     

  8. まあ、全体としてはうまくいっているでしょう。
    そこで、少なくとも「enumeration」がうまくできるかどうかを見るために、いくつかの年代の法令XMLを変換時に指定します。

  9. いちいち、中身を見て「平成」なのか「昭和」なのかを見るのは面倒なので、適当にいくつかピックアップしました。

  10. さて、これで生成するとどうでしょう。
    やはり取れないです。
    それはそうか。列挙されるリストが、どこまで長くなるかはわからないし、それ以外にも値が出てくるかもしれないし。

    <xs:attribute name="Era" use="required" type="xs:NCName"/>

     

  11. アウトラインだと比べやすいかな、と思ったのですが、並びが違うのでまだわかりにくい。

XSDのアウトラインを比較

ただ、わかったことは、公式なXSDでは、もっと多くの要素がXSDで定義されていて、おそらく、変換時に全XMLファイルを指定して、抽出したとしても完全なものは作れないということです。

 

まあ、XSDを見ようとする人は、XMLを知っていて、本来のルールに会うように、XSDを変更することができる人が多いと思うので、そこまでを(高価ではない)ソフトには求めていない、ということになるんでしょうね。

XMLBluePrintの日本語の表示問題が直った件

XMLBluePrintの日本語の表示問題が直った件

 

以前の記事で、表示を「游ゴシック」から「MS ゴシック」に変えたら、文字が重なってしまってひどいことになってしまう、と書きました。

 

で、XMLBluePrintの開発元に連絡してみたら、なんと、すぐに修正してくれて新しいバージョンが届きました。

開発元曰く、「MS ゴシック」以外のフォントでも問題が再現できたそうです。

 

これが修正しているバージョンは「21.20240307」です。これ以降のバージョンであれば問題は修正されているということになります。

念のため、表示のBeforeーAfterを載せておきます。どちらも、「MS ゴシック」での表示です。

 

【BEFORE】

修正前のバージョン

【AFTER】

修正後のバージョン

よく使うフォントフェイスで正しく表示されるのはありがたいです。

 

以上、情報を更新しておきます。

 

XMLエディター・XMLBluePrintでExcelをXMLに変換してみた

XMLエディター・XMLBluePrintでExcelをXMLに変換してみた

 

次のようなExcelファイル(.xlsx)があるとして、これをXMLBluePrintを使ってXMLに変換する方法をまとめたので、それを書きます。

 

(カッコよく見せるために。少しお堅めのタイトルを選んでみました (^_^; )

 

  1. 「ファイル」メニューから開くのではなく、「ツール」メニューから「ExcelをXMLに変換...」を選択します。

  2. 「参照」を押して、変換するExcelファイルを指定します。

  3. 「シナリオ」というのは「変換シナリオ」を指していて、以前にシナリオを保存していなければ、プルダウンには何も表示されません。

    今回は「新規」でシナリオを作ります。

  4. すると、指定したExcelファイルを読み込んで次のような画面になります。

  5. シナリオの名前はテキトーにつけておきます。

    「ワークシート」はExcelのワークシートです、1つしかないので、メニューに1つだけ表示されます。

    「指定行のヘッダー」は見出しの行を指定し、データの開始行と終了行を指定します。今回は、「指定行のヘッダー = 2」「データは次の行から開始=3」「データは次の行で終了=5」となります。

    すると、その下の「値」という欄が変わります。

  6. ひとまず「テンプレート」の欄は飛ばして、「プレビュー」の欄を見てみます。これを見ると、見出しの行をタグとして、データが認識されていることがわかります。

    これを見てから「テンプレート」の欄を見ると、テンプレートが何を指しているか、よくわかると思います。「$」で始まる部分は、ヘッダーから値を抜き出してその文字列を挿入する部分です。

  7. 「OK」を押すと、元の画面に戻りますが、今度はプレビューがついています。

  8. 「変換」を押します。プレビューそのままのXMLが生成されたので、これを「ファイル」=>「保存」すれば完了です。

 

パッと見てわかるんですが、デフォルトのフォントは日本語の表示にはむいていないようです。
「設定」=>「フォント」で確認すると、「Verdana」となっています。

「MSゴシック」がいいだろう、と変えてみると悲惨なことに。

どうもこれはだめみたいです。

「游ゴシック」にすればきれいに表示されます。

一応、サポートには連絡してみた。治るかな。

 

※(この問題は2024年3月8日に修正されているので、その記事も見てください)

 

XMLエディター・XMLBluePrintのセキュリティの問題は解決済

XMLエディター・XMLBluePrintのセキュリティの問題は解決済

 

XMLBluePrintで検索すると、

https://jvndb.jvn.jp/ja/contents/2019/JVNDB-2019-013889.html

のようなセキュリティの問題がヒットします。

これ以外には日本語ページがないせいかもしれませんが。

 

これは、XMLBluePrintバージョン16までの問題で、バージョン17では治ってます。

https://www.xmlblueprint.com/what-is-new.htm

 

現在の最新版はバージョン21なので、はるか昔に治っているということですね。

よかったです。

これで安心して使える。